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METHOD AND SYSTEM FOR COMMUNICATING WITH 
A WIRELESS DEVICE 



10 



BACKGROUND OF THE INVENTION 

The invention relates to systems and methods for 
communicating with wireless devices. 

15 Many systems today use wireless devices to transmit 

information. Television remote controls transmit information to a television 
via infrared signals. Cellular phones use radio frequencies to send and receive 
information. Wireless systems for monitoring inmates in a location employ 
the tight coupling of a transmitter on an inmate to the center point receiver in 

20 order to alert a "break out" condition when the inmate wanders outside the 

allowed radius of the receiver. In order for any transmitter in such systems to 
communicate with it's corresponding receiver, that receiver needs to know 
intimate knowledge about the types of transmitters attempting the 
communication, the protocols those transmitters are using, and specific 

25 instance information about the particular transmitters. 

In a first example, television remotes are made for and are hard 
wired for a particular television or class of televisions that those remote 
controls control. The knowledge in this system about the types of remote 
control transmitters that the receiver television expects is intimately bundled 

30 together since the television remote comes in the same package as the 
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television. There is also an implicit understanding that the receiver television 
will understand the remote control transmitter bundled with that television. 
The knowledge about the protocols used by the remote control to 
communicate with the television are hard- wired into the remote as specific 
5 infrared signals that are sent when certain buttons are pressed. The television 

knows what to expect because it is hard-wired to receive and process a specific 
set of signals. As such, only a remote made for that particular television or 
class of televisions is able to communicate with that television and is able to 
be used to control that television - - with the caveat that learning remotes, 

10 universal remotes, and the like, can mimic the particular remote in question. 

In such a system, registration is not necessary as the hard- wired nature of the 
transmitter and receiver programmed at the factory serve as the only 
registration necessary. Such a level of simplicity is desirable in certain 
systems, but the flexibility and lack of transmitter uniqueness in such a system 

15 is undesirable. 

As a second example, a cellular telephone operates in a very 
different manner. Cellular telephones work on the principle that each specific 
instance of a telephone handset is different, and the exact identification of 
particular instances of a cellular telephone is critical. A cellular provider only 

20 wants individuals registered with their services and in good standing to use 

their networks. Not every cellular telephone is able to or should be allowed to 
use the network. The electronic subscriber number, or ESN, is used at 
registration time to identify cellular phones within the system. In fact, 
typically, a user must call the service provider and verbally provide the ESN in 

25 order to be allowed access to services on that service provider's network. 

Each time a call is placed, the ESN serves as the authentication token to gain 
access to the network. The ESN is stored on the service provider's system and 
compared against the one sent by the phone when a call is made or when 
heartbeat event occurs. 
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The particular protocol used can then be programmed into the 
phone at registration time or may have already been programmed into the 
phone earlier. Such a system creates an ownership and privilege relationship 
between the phone and the service provider which can be crucial since 
5 increasingly large numbers of individuals make use of wireless devices in 

close proximity to one another. As such, it is important to prevent spurious 
devices from gaining access to a user's local domain. The identification of a 
wireless transmitter with it's associated receiver through registration, as in 
cellular phone registration, is the solution. However, such a process can be 

10 cumbersome enough for one phone and is especially burdensome when a user 

needs to register ten, or even one hundred, phones. 

In a third example, The wireless inmate tracking devices are a 
hybrid of the above two concepts. Like cell phones, these devices can use an 
authentication scheme similar to the ESN scheme employed by cell phones. 

15 These wireless monitoring systems transmit a packet of information at a 

designated time interval in order to note the existence of the inmate. If an 
appropriate packet is received within the time interval specified, then the 
inmate is deemed to be in the acceptable radius while the absence of a 
regularly scheduled packet signifies the possible escape of such an inmate. To 

20 avoid the possibility that a person could use a similar device to mimic their 

tracking device, and, thus, escape under the guise of perceived existence, an 
authentication token can be used that is similar to an ESN. The affinity gained 
by such an ESN-like scheme captures the unique relationship necessary to 
correctly identify and distinguish the presence of the inmate within the 

25 allowable radius. The registration for such devices, however, are often 

hardwired by the manufacturer, the manufacturer burning in the identification 
information on both the transmitter and the receiver and shipping both 
transmitter and receiver bundled together. Such devices possess the ease of use 
inherent to television remote controls which do not require unique identifiers, 
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but they still suffer from the requirement that identifying information must be 
hard-coded by the manufacturer. 

Thus, there exists a need to have a system in which the 
registration of the transmitter devices is flexible and sufficiently easy to 
5 perform by a user, which can be performed repetitively without becoming 

burdensome. In addition, there exists a need for the system which, at the same 
time, guarantees the uniqueness of the transmitter devices and allows access 
restrictions necessary for users to effectively manage their local domain of 
devices. It is therefore an object of the present invention to provide improved 

10 systems and methods for registering and authenticating wireless devices. 

Another problem that frequently arises in many wireless 
receiver/transmitter systems is the problem of clock drift between the 
controller 28 (the receiver) and the wireless control devices 210 (the 
transmitter). This is especially the case where inexpensive asynchronous 

1 5 transmitters and/or receivers are utilized that have inexpensive RC oscillators 

or the like that serve as the clock. Typically, these RC oscillators are unstable 
clocks and require periodic resynchronization to be useful. What's more, the 
slight variation in the current drawn from batteries, which many of these 
wireless control devices use, frequently cause the oscillators to run at slightly 

20 skewed rates as compared one to another. As such, these inexpensive receivers 

and transmitters which have unstable clocks are prone to drifting out of 
synchronization over time, causing errors in the data that often cannot be 
recovered from. 

Because a data bit exists as either a high voltage signal or a low 
25 voltage signal, for encoding a 1 or a 0, and because that voltage is changed 

every regular time interval, clock drift can quickly cause the transmitter and 
the receiver to think that one is sending one bit while the other is reading 
another bit. In a transmitter/receiver system with a one second clock drift after 
five seconds and a one second time interval serving as the regular window in 
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which a bit is encoded, after five seconds a receiver would be out of sync by 
an entire bit after 5 bits, causing the receiver to think that it is reading either 
the sixth or the fourth bit after the first five seconds. It is clear that such a data 
read would be erroneous. 
5 One solution is to employ the use of highly synchronized 

crystals to keep a regular time in the transmitter and the receiver. For several 
reasons, this is undesirable generally. For fairly "inexpensive" devices, such as 
a light switch or a smoke detector, the grade of synchronized crystals needed 
to keep the clock drift problem at bay can result in a significant cost of the 

10 manufacturing of such "inexpensive" devices going to the cost of the crystals. 

Moreover, the data pins on a microprocessor in "inexpensive" devices are 
often in short supply as product manufacturers squeeze more functionality out 
of these "inexpensive" devices. A crystal can take up more than one pin while 
more traditional systems, perhaps using the clock inherent in battery-based 

1 5 clocks, take up only one pin on the microprocessor. 

Therefore it is another object of the present invention to find a 
scheme which allows devices employing "inexpensive" oscillators to be used 
in a way which will allow arbitrarily long multi-byte transmissions in the face 
of clock drift. 

20 

SUMMARY OF THE INVENTION 

This and other objects of the invention are accomplished in 
accordance with the principles of the present invention by providing a method, 
system, transmitter, receiver and protocol are disclosed for communicating 
25 with wireless receivers. The invention includes providing a controller having 

a discovery mode and an operating mode, in the discovery mode the controller 
is capable of registering wireless devices, in the operating mode the controller 
is capable of receiving transmissions from a wireless device that has been 
registered. A wireless transmitter is provided which is capable of 
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communicating wirelessly with the controller. The wireless device has an 
actuator for initiating at least one transmission of registration data. When the 
controller is placed into the discovery mode, and the actuator of the wireless 
device is actuated to wirelessly transmit the registration data from the wireless 
5 device to the controller, whereby the wireless device is registered with the 

controller. The wireless data contains data that allows the controller to 
interface with the wireless device. 

The data that allows the controller to operate the wireless 
device may include parameters, device descriptors, and rules associated with 

10 the operation of the wireless device. 

In one form of the invention the wireless device comprises an 
RF transmitter capable of receiving RF transmissions from the wireless device. 
The wireless device may further comprises an IR transmitter capable of 
receiving IR transmissions from the wireless device. In the discovery mode of 

1 5 the controller, the wireless device may transmit the registration data via the IR 

transmitter to the controller. 

The actuator of the wireless device may comprise a mechanical 
control, an electrical control, a software control, a physical control, a tactile 
control, or an audible control. 

20 The wireless device may be a wireless sensor having a sensor 

front end for receiving event data. The wireless sensor may include a non- 
volatile storage device for storing a serial number associated with the sensor 
device. The non-volatile storage device further stores functional parameters 
for the sensor front end and the functional parameters for the sensor device 

25 may be transmitted along with the registration data. 

In one form of the invention, the controller returns to the 
operational mode automatically after at least one wireless device has been 
successfully registered. In another form of the invention, the controller returns 
to the operational mode automatically after a preselected time interval. In yet 
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a further form, the controller includes an actuator for switching between the 
operational mode and the discovery mode. The actuator of the controller may 
comprises a mechanical control, an electrical control, a software control, a 
physical control, a tactile control, or an audible control. 
5 The at least one transmission of registration data may comprise 

a first signature byte for identifying that the at least one transmission is a 
registration transmission. The at least one transmission of registration data 
may also comprise a plurality of sequential transmissions. One of the 
registration data transmissions may comprise a first signature transmission for 
10 identifying that the subsequent transmissions are registration transmissions. 

One of the registration transmissions may comprises a serial number for 
identifying the wireless device. The serial number may be a unique serial 
number. 

One of the registration transmissions may include a second 
15 signature transmission, the second signature byte may be identical to the first 

signature transmission. 

At least one of the registration transmissions may include a circular 
redundancy check transmission. At least one circular redundancy check 
transmission may include a plurality of circular redundancy check 
20 transmissions. 

In one form of the invention, the at least one transmission of 
registration data includes at least nine transmissions comprising a first 
signature transmission, a first serial number transmission, a first data 
transmission, a second serial number transmission, a third serial number 
25 transmission, a second data transmission, a second signature transmission, a 

first circular redundancy check transmission, and a second circular redundancy 
check transmission. 

In one form of the invention, the data transmission includes a 
synchronization pulse. The synchronization pulse may be located at the start 
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of each data transmission. The synchronization pulse may comprise at least 
one ON bit and at least one OFF bit or two ON bits and one OFF bit. The 
controller may resynchronize at the trailing edge of the final ON bit. 

A protocol for registering and authenticating wireless device is 
5 provided which includes a multi-byte transmission of data having at least one 

signature byte, at least one data byte, at least one serial number byte, and at 
least one circular redundancy check byte. Each byte of the multi-byte 
transmission comprises at least one synchronization bit. The at least one 
signature byte may comprise a first signature byte and a second signature byte. 

10 The at least one circular redundancy check byte may include a first circular 

redundancy check byte and a second circular redundancy check byte. The at 
least one serial number byte may comprise a plurality of serial number bytes 
and/or a plurality of data bytes. In one form of the protocol, the multi-byte 
transmission of data comprises a first signature byte, a first serial number byte, 

15 a first data byte, a second serial number byte, a third serial number byte, a 

second data byte, a second signature byte, a first circular redundancy check 
byte, and a second circular redundancy check byte. 

The synchronization bit may be located at the start of the 
transmission, and may comprise at least one ON bit and at least one OFF bit or 

20 two ON bits and one OFF bit. The protocol can be a one-way protocol or a 

multi-way protocol. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of this invention, reference 
25 should now be made to the embodiment illustrated in greater detail in the 

accompanying drawing and described below. In the drawings: 

FIG. 1 is a block diagram of an illustrative system for 
communicating with a wireless device in accordance with a first embodiment 
of the present invention. 
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FIG. 2 is a block diagram of a controller for use in the invention 

of FIG. L 

FIG. 3 is a block diagram of a wireless device for use in the 
invention of FIG. 1. 
5 FIG. 4 is a block diagram of the TEST/Registration 

transmission of the invention of FIG. 1. 

FIG. 5 is a timing diagram of a transmission sent by a wireless 
device of the invention of FIG. 1. 

FIG. 6 is a block diagram of an illustrative system for 
1 0 communicating with a wireless device in accordance with a second 

embodiment of the present invention. 

FIG. 7 is a block diagram for the steps involved in carrying out 
a registration process of the invention of FIG. 6. 

FIG. 8 is a block diagram of an attempted registration by a 
15 malicious user in accordance with the second embodiment. 

FIG. 9 is a block diagram of an illustrative system for 
communicating with a wireless devices in accordance with a third embodiment 
of the present invention. 

FIG. 10 s a block diagram of some of the components of the 
20 illustrative system for communicating with a wireless device of FIG. 9 in 

accordance with the third embodiment of the present invention. 

FIG. 11 is a block diagram of some of the components of the 
illustrative system for communicating with a wireless device of FIG. 9 in 
accordance with the third embodiment of the present invention. 



25 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

In FIG. 1 there is shown a wireless receiver/transmitter system 
in accordance with the present invention. The receiver/transmitter system 110 
includes a controller 28 and one or more wireless control devices 210, such as 
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sensors, appliances, VCRs, microwave ovens, and thermostats. The controller 
28 is capable of interfacing with various wired devices 32, such as a camera 
34, a microphone 33, and a motion sensor 35, and is capable of receiving data 
transmissions from the wireless control devices 210. 
5 A schematic diagram of the controller 28 is depicted in FIG. 2. 

The controller 28 includes a main microprocessor 1 12 for controlling a 
primary wireless receiver, such as an RF receiver 1 14, and a switcher circuit 
124. The RF receiver 114 includes an RF antenna 1 16 for receiving RF 
signals transmitted by the wireless control devices 210. Typically, the RF 

10 receiver 114 may have its own processor or may use the resources of the main 

microprocessor 112. It should be understood that any suitable receiver capable 
of receiving wireless communications, such as an RF or a microwave receiver 
is within the scope of the present invention. 

The Controller may also include a registration channel receiver, 

1 5 such as an IR receiver 120, that is capable of excluding registration of 

unintended or unauthorized transmitters and inadvertent registration of 
transmitters with unintended or unauthorized receivers. For example, IR 
communications require line-of-sight proximity between the transmitter and 
receiver and are capable of excluding out or range communications. So for 

20 example, a user trying to register a wireless camera device having an IR 

transmitter must typically be in the same room with the receiver controller in 
order to effect the transmission of data therebetween and would typically not 
be able to communicate with a receiver controller that is located down the 
street or at a neighbor's house. Similarly, encrypted communications are also 

25 able to exclude unauthorized communications without access to the encryption 

key. For example, a transmitter may require a smartcard having an encryption 
key that is known to a particular receiver in order to communicate with that 
receiver, transmitters without this smartcard would not be able to 
communicate with the reciver. Of course, any suitable secure channel receiver 
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could be substituted for the IR receiver 120 depicted in the illustrated 
embodiment. 

The infrared receiver 120 includes an infrared signal receiver 
126, such as an LED, for receiving infrared signals emitted from the wireless 
5 control devices 210. The infrared receiver 120 typically uses the resources of 

the main microprocessor 1 12, but it may include its own microprocessor. 

The switcher circuit 124 is in two-way communication with the 
main microprocessor 1 12. The switcher circuit 124 functions to switch 
between various video, audio, and/or data inputs from wired control devices 

10 32 connected thereto and functions to connect the switched inputs to an output 

port 143. The switcher circuit 124 includes a first input port 135 having a first 
video input 126, a first audio input 128 and a first data input 130. The video 
output 180 of the camera 34 may be connected to the first video input 126, the 
audio output 182 of the microphone 33 may be connected to the first audio 

15 input 128, and the data output 184 of the motion sensor 35 may be connected 

to the first data input 130. Of course, the first input port 135 can interface with 
any device having video, audio, and/or data outputs. 

The switcher circuit 124 also includes a second input port 137 
having a second video input 132, a second audio input 134, and a second data 

20 input 136 for communicating with a second control device 32 having video, 

audio, and/or data outputs. The switcher circuit 124 can also include any 
number of additional input ports for interfacing with and switching between 
additional control devices having video, audio, and/or data outputs 32. In the 
embodiment shown in FIG. 2, two additional sets of input ports 139 and 141 

25 are depicted. 

The input ports may receive video, audio, and data inputs in 
any combination, such as a audio/video source attached to the audio and video 
ports of the first input port, a microphone attached to the audio input of the 
second port, a video-only source attached to the video input third port, and a 
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data source attached to the data input of fourth port. The number of ports is 
merely illustrative, and it is contemplated that there can be any number of 
switched input ports. 

The switcher circuit 124 also includes an output port 143 
5 having a video output 140, audio output 142, and data output 144. The 

switcher circuit functions to switch between any video, audio, and/or data 
input of any of the input ports with the respective video, audio, and/or data 
output of the output port 143. 

Also included is a communication link 138 connecting the 

1 0 switcher circuit with the main microprocessor 1 12 for passing signals 

therebetween. The video 140, audio 142, and data 144 outputs of the switcher 
circuit 124 are in communication with a client interface 150, such as a USB 
interface set. The client interface 150 is in communication with the client 
access device 22 such as a personal computer (PC). In operation, the switcher 

1 5 circuit 124 switches between any of the video, audio, and data outputs of any 

of the device sources 32 connected thereto and the video, audio, and data feeds 
of the switcher output 143 for communicating the signals to the client access 
device 22. In addition, RF and IR signals received by the RF receiver 116 and 
IR receiver 120, respectively, may be routed by the main processor 1 12 to the 

20 client access device 22. 

The controller 28 includes a controller actuator 122 for 
switching between a DISCOVERY mode and an operational mode of the 
controller 28. The actuator can be any suitable device that is capable of 
switching between modes of the controller, such as a mechanical button or 

25 control, a software control, an electrical control, a physical control, a tactile 

control, an audible control, or the like. The operational modes of the 
controller are described in greater detail below. 

A typical wireless control device 210 is depicted in FIG. 3. It is 
contemplated that the wireless control device may be any type of device such 
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as an appliance, clock, or any device that is capable of transmitting data. In 
addition, the wireless control device may be a sensor type device having a 
sensor front end for receiving sensor data. The device depicted in the 
preferred embodiment is depicted as a sensor-type device since such a device 
5 encompasses other simpler wireless transmitters. The wireless control device 

210 may include a main microprocessor 212. The wireless control device 210 
may also include a sensor front end 214 in communication with the main 
processor 212. The sensor front end 214 functions to capture events and 
convert the event data received to a form, typically a digital form, that the 

10 microprocessor 212 understands. It should be understood that non-sensor 

devices do not include sensor front ends and merely function to transmit data. 
It is contemplated that a device, such as a motion detecting camera, may have 
a sensor front end, and, as such, can perform all the tasks of a sensor front end 
wireless control device as well as the tasks of a non-sensor front end wireless 

15 control device. 

The wireless control device 210 further includes a non- volatile 
storage device 216 such as an EEPROM, ROM, or the like. This non- volatile 
storage device 216 may store a unique serial number for the device; particular 
functional parameters of the control device; such as those for the sensor front 

20 end 214, for use by the microprocessor 212; and encryption data. 

A primary channel transmitter, such as an RF transmitter circuit 
220, is provided for transmitting radio frequency signals. The RF transmitter 
circuit 220 includes an RF transmitter 222 for transmitting the RF signals. 
The wireless control device 210 may also include a registration channel 

25 transmitter, such as an infrared transmitter circuit 224 having an IR emitter 

226 for emitting IR signals. Typically, the registration channel is used for 
securely transmitting registration information to the controller 28. If a 
registration channel transmitter or receiver is not provided in the system, the 
primary channel is typically used to transmit registration data. 
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The wireless control device 210 may also include an encryption 
or security module or circuit 228 that includes a set of commands, programs, 
and/or algorithms which manipulate the data transmitted by the wireless 
control device to secure the transmitted data, by encryption, using code 

5 substitutions for signal "words," XOR'ing the transmitted data, or any other 

suitable method for making the transmitted data more secure. The 
functionality of the encryption module 228 may be incorporated into the non- 
volatile storage device as discussed below. 

The wireless control device 210 may also include a wireless 

10 control device actuator 230 for sending a preselected or generated transmission 

of data to the wireless control device. The actuator 230 may be any suitable 
switch-type device such as a button, switch, lever, or other mechanical, 
electrical, software, or the like controller. In the embodiment depicted in FIG. 
3, the actuator is illustrated as a mechanical button. 

15 In another embodiment of the present invention, an actuation of 

the wireless control device 210 is not required. In this embodiment a heartbeat 
transmission for maintaining or synchronizing the state of the device may 
serve as the registration transmission of the registration data. An example of 
such a system is depicted in connection with the third preferred embodiment 

20 illustrated in FIGS. 9-11. As discussed earlier, in addition to sending out 

registration information and event transmissions, a wireless control device 210 
also sends out regular heartbeat transmissions. These heartbeat transmissions 
may contain the same information as the registration transmissions which are 
typically sent out when the wireless control device actuator 230 is actuated. 

25 The order and number of the bytes for these heartbeat transmissions may be 

the same as the order and number of bytes of a typical registration 
transmission. If the controller 28 is in DISCOVERY mode when a heartbeat 
transmission is transmitted by the wireless control device 210, the wireless 
device 210 may be registered with the controller 28 as it would if a registration 
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transmission was transmitted by the actuation of the actuator 230. Such a 
heartbeat registration is asynchronous and does not rely on human 
intervention. Upon the registration of a wireless device by the occurrence of a 
heartbeat registration, the controller 28 would return to the operational mode. 
In this embodiment, placing the controller 28 in DISCOVERY mode is the 
only human intervention required. 

In the illustrated embodiment of the present invention, the 
wireless transmitter 210 can include various types of devices and sensors such 
as a door contact sensor, a water level sensor, and acoustic sensor, a POWER 
ON sensor, a temperature sensor, a smoke sensor, a carbon monoxide sensor, a 
radon sensor, heat sensor, and the like. Each of these sensors is well-known in 
the art and functions to sense different types of events as is well-known to 
those skilled in the art. For example, the POWER ON sensor may have a 
sensor front end that is capable of detecting a 60 Hz AC current of an electrical 
device. Similarly, a water sensor typically has a front end which is able to 
detect an impedance when in contact with a liquid medium. 

In normal operation, the wireless control device 210 functions 
to transmit RF signals via the RF transmitter circuit 220 to be received by the 
RF receiver antenna 116 of the controller 28. Typically, the sensor front end 
214 receives events which are converted into electrical or digital signals and 
passed to the processor 212 where they are processed and passed to the RF 
transmitter circuit 220 for transmission. For non-sensor devices, data is 
merely passed to the transmitter circuit for transmission. In addition, if the 
wireless control device 210 is provided with an infrared transmitter circuit 224 
and is within the line of sight of the IR infrared receiver of the controller 28, 
infrared transmissions may be transferred between the wireless control device 
210 and the controller 28 as described in greater detail below. 

One aspect of the present invention is concerned with the 
ability to automatically detect a wireless control device and register that device 
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with the receiver/controller 28. To effect the auto-detection, the present 
invention contemplates placing the controller 28 into a DISCOVERY mode by 
activating the controller actuator 122 or by otherwise placing the controller 28 
in a DISCOVERY mode. In the preferred embodiment, this is done by 
5 making selections in the software interface of the client access device 22 to 

send an electrical transmission to the controller 28 to listen for the wireless 
control devices. It should be understood that there are many other suitable 
ways for placing the controller 28 into DISCOVERY mode, such as by 
actuating a mechanical or electrical button or switch located on the controller 

10 or some other associated device, by having the transmission of the wireless 

control device place the controller 28 in DISCOVERY MODE, by providing a 
voice recognition module for recognizing a command for placing the 
controller 28 in DISCOVERY mode spoken by the user, or the like. The 
controller 28 may exit DISCOVERY mode by any suitable way, such as by 

15 activating the actuator 122 again, by automatically exiting the DISCOVERY 

mode upon reaching a preselected time interval, upon a successful registration 
event, or the like. 

Once the controller 28 is in the DISCOVERY mode, the user 
actuates the wireless control device actuator 230 to send the preselected 

20 transmission which preferably, and not by way of limitation, includes a series 

of data transmissions to the receiver describing authentication information, 
device type information, device state, and error-checking information, as 
described in greater detail below. Once the receiver detects an end of 
transmission from the wireless control device, the control device is 

25 successfully registered by the system. Once registration is successful, the 

wireless receiver may exit DISCOVERY mode either automatically or by 
actuation by the user and return back to its normal operational mode. 

In one form of the invention, the controller 28 needs to know 
that such a class of device desiring registration exists, requires registration, 
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and needs to know how to handle them for future reference in order to 
complete a successful registration. For example, in order to register a 
temperature sensor in the current implementation, the temperature sensor 
device type is encoded as a portion of the three byte serial number discussed 
below. This device type is received by the microcontroller 1 12 via the RF 
antenna 1 16 or the IR receiver 120. The device type is then passed to the 
client access device 22 and a proper entry is made in the software to associate 
the serial number from the wireless control device 210 just registered with the 
device type sent as part of that registration transmission. 

In another form of the invention, the particular wireless device 
and its particular functionalities can be unknown to the receiver at the outset 
and all registration data and data needed to operate the device can be 
transmitted during the registration process. To demonstrate this, the controller 
28 begins in discovery mode. The registration may be effected by actuating 
the wireless control device actuator 230 on wireless control device 210. The 
transmission is sent from a wireless control device 210 to controller 28 using 
RF or IR signals. The device type information located in the serial number 
byte or bytes, as described below, contains the device type for an "unknown" 
device. This indicates to the controller 28 that information in the subsequently 
transmitted data bytes will contain a description of the device, including all the 
rules necessary to process the information from that device. These data bytes 
may, in one embodiment, include rules as java code segments, methods, and 
procedures in a preselected format. Other methods of transferring rules 
include byte code, alternative structured programming languages, text, XML, 
and the like. Upon receiving these rules, the controller 28 executes a set of 
methods to store and install the rules associated with the particular serial 
number of the wireless control device 210 being registered. Once the end-of- 
transmission is detected, the wireless control device can begin operating in 
operational mode and the controller 28 will contain the rules necessary to 
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interpret the information from the wireless control device 210 in order to take 
proper action on that data. 

In another embodiment, parameters that specify what type of 
device is being registered may be sent. A controller may receive a transmission 
5 which specifies certain parameters that describe a device. The controller may 

be programmed to expect certain keywords and to take particular actions based 
on the values of those parameters. For example, if the controller receives the 
keyword "rangemax" and a value 100 and a keyword "rangemin" with the 
value 0 ? it could be programmed to automatically assume that this is a device 

1 0 with a range element (like a slider). In addition, another parameter might be 

"button state 1" with a value of "power on" and a second "button state 2" with 
a value of "power off 1 . In this case, the intelligence for managing the device 
exists in the device itself, and the controller serves simply to forward the data 
back and forth between the client access device in the device's particular 

1 5 transfer medium. In the previous example, an entire java code object, in this 

case a device driver, could be uploaded by the device to the controller as part 
of registration. This device driver may simply subclass the super class device 
driver and may be required to contain certain methods that the controller can 
execute in order to pass information to and from the object. The object may 

20 then be responsible for managing the export of its virtual interface, scheduling 

updates, interpreting transmissions from the device, or any other activities 
needed in order to manage and run the device. 

In the DISCOVERY mode of the controller 28, the controller 
28 is placed in a state in which it is programmed to listen for transmissions 

25 from the wireless control devices which desire to be registered. In 

DISCOVERY mode, all transmissions which are not registration transmissions 
may, but not by way of limitation, be ignored during the process, allowing the 
receiver to specifically listen for particular registration transmissions from the 
wireless control devices and to filter out any erroneous transmissions. For 



DSB:753070.3 



-18- 



example, a special signature byte, a special code in the data field, or the like 
can be used to identify the transmission as a registration transmission. In such 
a case, the controller, in discovery mode, is able to ignore all transmissions 
that do not have the signature byte or special registration code. 
5 When the actuator on a wireless control device is activated, the 

wireless control device is forced to send a preselected or generated 
transmission containing relevant registration information to the controller to 
allow the controller to properly register that device when the controller is in 
DISCOVERY mode. In one suitable embodiment of the present invention, 

1 0 When the controller is not in DISCOVERY mode, the preselected 

transmission may be used as a TEST-type transmission to determine whether 
the controller 28 is capable of receiving transmissions from the wireless 
control device under current conditions in order to test for out of range, 
impeding obstacles, excessive ambient noise, and the like. 

1 5 The registration transmission can be accomplished by 

transmitting the registration signals via the RF transmitter or the IR 
transmitter. Transmitting via the IR transmitter ensures that a particular 
controller will only receive registration transmission from wireless control 
devices that are within the line of sight of the controller. This is a security 

20 feature that allows the controller 28 to receive only transmissions from 

wireless control devices in a relatively close range and which prevents 
inadvertent and/or intentional registration of wireless devices by other nearby 
users. 

When the wireless control devices 210 are in the operational 
25 mode, they are capable of transmitting events, such as a change of state of a 

door sensor (from open to closed), a scheduled heartbeat, or a maintenance 
signal. The purpose of the heartbeat or maintenance signal may be a periodic 
or scheduled transmission that updates the controller 28 as to the status of the 
controlled wireless device 210. 
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For one embodiment of the present invention, when the 
wireless control device actuator 230 of the wireless control device 210 is 
activated by the user, the wireless control device 210 transmits a preselected or 
generated transmission or series of transmissions. When the controller 28 has 
5 been placed in DISCOVERY mode by activation of the actuator 122, the 

series of transmissions may, in one embodiment, serve as an announcement or 
registration of the controlled wireless device 210 in the wireless domain. 
Conversely, when the controller 28 is in its operational mode, the test data 
transmission may serve, in one embodiment, to ensure that the wireless control 

10 device 210 is in range of the controller 28 and/or whether conditions are 

conducive to transmitting and receiving RF signals, i.e., there is not too much 
RF interference or other wireless interference and noise. 

The structure of the test or registration transmission comprises 
a series of transmissions that include authentication information, device type 

15 data, device state data, and error checking information. In the preferred 

embodiment, each transmission of data is a byte, or eight bits, in length. 

As best seen in FIG. 4, the preferred structure of the test or 
registration transmission 250 comprises a series of nine bytes of data. The 
first byte 252 is the first of two signature bytes that is used to denote the 

20 beginning of the registration sequence. The second byte 254 comprises the 

first of three serial number bytes that contain the type of the device and to 
provide any sort of type information necessary to process later data bytes. The 
serial number and device type data are typically stored in the non- volatile 
memory 216 of the wireless device. In addition, the first serial number byte 

25 254 may be used to set the controller 28 into a mode where it can correctly 

categorize the controlled wireless device 21 0. For example, information 
relating to the wireless device, device type, where it was purchased, its age, 
and the like may be encoded into the serial number information which is 
passed and used by controller 28. 
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The third byte 256 comprises the first of two data bytes that 
may contain any sort of information that needs to be transmitted. For purposes 
of the present invention, the first data payload byte may contain on/off 
information and any other discreet state information associated with the 
5 controlled wireless device 210, such as the number of colors that a lamp may 

contain or the set of values to expect for a temperature sensor. Thus, the data 
contained in the first data payload can be combined with additional 
information contained in the next data bytes to fully describe the state of the 
device. For example, the first data payload byte can include a pan and tilt code 

10 signifying whether the update is a pan or a tilt update for a movable camera 

and the second data payload may contain specific pan and tilt values. 

The fourth byte 258 is the second of three serial number bytes, 
and the fifth byte 259 is the third of the three serial number bytes. The first, 
second and third serial bytes together serve as the authentication and 

15 identification codes for the wireless control device. Once the wireless device 

has been successfully registered, the controller 28 may only accept 
transmissions from devices bearing this serial number, some other already 
registered serial number, or other devices that are being registered while the 
controller is in DISCOVERY mode. 

20 The sixth byte 260 contains the second of two data bytes and 

may include any additional device specific information or the like that might 
be needed during the transmission. 

The seventh byte 262 comprises the second of two signature 
bytes. In one form of the invention, this second signature byte 262 is identical 

25 to the first signature byte 252 and is used as a data integrity check as discussed 

in greater detail below. In another invention, the first signature byte can 
signify which protocol is used. In this case, the second signature byte can be a 
different value, and, when paired with the first signature byte, is understood by 
the controller as the total identifier expected by the protocol. Of course, other 



DSB.753070.3 



-21- 



schemes for the signature bytes are known and within the scope of the present 
invention. 

The eighth 264 and ninth 266 bytes comprise a first circular redundancy check 
(CRC) and a second circular redundancy check (CRC) that are used to 

5 guarantee that the data is intact. Typically, the CRC bytes 264 and 266 are 

used in a checksum algorithm, as is well-known in the art. 

Because it is so difficult to accurately and reliably transmit data 
in a wireless environment under typically noisy conditions, four out of the nine 
bytes transmitted are present to guarantee the integrity of the transmitted data. 
10 As each byte of the transmission is transmitted by the wireless control device 

210, it is received and processed by the controller 28. By processing each byte 
of the data as it is received, as opposed to waiting until the last byte of data has 
been received and then transmitting the entire transmission of data, the system 
is able to quickly identify and discard corrupt data or noise. Thus, it is 

1 5 possible to ensure with a high degree of certainty, the reception of accurate 

transmissions. 

For example, the second signature byte 262, as received by the 
controller 28, must correspond to the byte expected by the practical use as 
described above, for the entire transmission 250 to be accepted. Of course, the 

20 CRC's could take other well known forms, such as a combined 16 bit CRC, 

that are within the scope of the present invention. If the signature bytes are not 
received as expected and/or the CRC bytes do not correspond to the CRC 
bytes expected, the entire transmission is ignored and discarded. 

Similarly, in one form of the invention, the first CRC byte and 

25 the second CRC byte are identical, as received by the controller 28, for the 

transmission to be accepted. Because there is a high rate of errors triggered by 
many random devices transmitting random RF signals, the presence of two 
data integrity checks in the redundant signature bytes 252, 262 and CRC bytes 
264 and 266 ensure with a high rate of certainty that accurate data has been 
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received by the controller 28 and not corrupted data or other noise. The fact 
that CRC's are built into the algorithm means that the data and serial number 
bytes are checked for internal integrity while at the same time providing an 
additional two bytes of noise cancellation. 
5 Once the entire nine byte transmission 250 has been received 

by the controller 28 and verified as being accurate, the controller 28 knows 
that it has detected a successful registration and is able to successfully 
authenticate and process the data received from the wireless device. The serial 
numbers serve as an authentication token and prevent interference from nearby 

10 controllers 28 and wireless devices in the user's space; spurious transmissions 

will be ignored because the serial numbers of these spurious devices are not 
registered with a particular controller 28. The DISCOVERY mode of the 
controller 28 may automatically time out or otherwise automatically end, 
whereupon the controller 28 returns to its normal operational mode. 

15 Alternatively, the controller 28 may be manually switched by the user to its 

normal operational mode by activating the actuator 122. 

The embodiment discussed illustrates a nine byte transmission 
scheme. It should be understood that the number of transmissions or the 
transmission length may contain any number of identification or signature 

20 bytes, data bytes, CRC bytes, or other checksum techniques for ensuring 

internal data integrity. The data bytes may contain any type of data besides 
sensor data, such as algorithms, hardware descriptions, encrypted data, video, 
audio, number of expected bytes, and the like. 

Also, it should be understood that the protocol of the present 

25 invention works as a one-way protocol, i.e., no response, acknowledgment or 

other transmission is required from the controller 28. It should also be 
understood that the protocol works for up to N-way communications, where N 
is greater than or equal to 1 . By N-ways, it is contemplated that a wireless 
control device may in fact register with multiple controllers 28 simultaneously 
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or at different times. 

In another embodiment of the present invention, a unique token 
may be transmitted along with the device registration transmission. The 
unique token is verified to be acceptable by any suitable registration or 
verification entity, such as the server 14 illustrated in the third preferred 
embodiment, whereupon the wireless control device 210 is successfully 
registered. 

Not by way of limitation, the unique token may be encoded in 
the three serial number bytes 254, 258, 259 which are transmitted to the 
controller 28 during a registration transmission. The controller 28 would send 
the unique token to the server 14 (FIG. 9), perhaps by way of the client access 
device 22. The controller 22 would receive back a response from the server 
notifying the controller whether that token was accepted by the server. Such a 
method is useful to detect whether the wireless control device has been 
previously registered in the system 1 10. If a proper user successfully registered 
the wireless control device previously, then the unique token would already be 
present on the server. If a second malicious user attempted to register the same 
wireless control device with the system 110, the server would refuse the 
attempted registration due to the previous registration by the proper user. 

As best seen in FIG. 5, the present invention solves the clock 
drift problem by inserting a synchronization pulse 290 at the beginning of each 
byte of data 292 transmitted by the wireless control device 210. In the 
preferred embodiment, the synchronization pulse 290 is three bits in length 
and comprises two ON bits followed by an OFF bit. The receiver recognizes 
this pattern as being a synchronization pulse and resynchronizes its clock at 
the trailing edge of the second ON bit. 

Depending upon such factors as the bit rate, the stability of the 
clock, the tolerance of the system, and the like, the transmitter and receiver 
may stay in synchronization for a number of data bits transferred. For 
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example, for a bit rate of 2400 bits/sec. (4 MHz), a tolerance of ±10 MHz, and 
a clock, the receiver transmitter system 1 10 is able to stay reliably in 
synchronization for at least 8 bits of transmitted data, which is sufficient to 
transmit one byte of data. It has been found that as long as the clock drift is 
5 less than l A of one bit by the conclusion of an eight bit transmission that the 

problem of clock drift is eliminated. Of course it should be understood that 
other combinations of factors could be used to accomplish the task of 
maintaining the synchronization of a relatively unstable clock over a selected 
data transmission window. 

10 In a second embodiment of the present invention depicted in 

FIGS. 6 and 7, we demonstrate how to securely and authentically 
communicate between wireless control devices and a controller and show how 
registration of wireless control devices takes place in order for this to happen. 
In this embodiment, a first proper controller 2500 and a second malicious 

15 controller 2505 are depicted. In this example, a wireless control device 2504 

first registers with the proper controller, and subsequently, a malicious user 
attempts to spy on the wireless control device 2504 registered with the proper 
controller 2500. The malicious user does this by way of attempting to register 
the wireless control device 2504 with the malicious controller 2505, thus, 

20 hoping to capture all events and data from the wireless control device 2504 

during operation. This embodiment contemplates detecting and notifying the 
user of such a security breach and as a way of showing the system described in 
connection with the first embodiment in a practical scenario. 

As shown in FIGS. 6 and 7, in step 2000, the proper controller 

25 2500 is placed in to DISCOVERY mode by the proper user by actuating the 

proper controller actuator 2502. In DISCOVERY mode, the proper controller 
2500 is in a mode where it is listening for IR and/or RF registration 
information from one or more wireless control devices that the proper user 
wishes to register. In step 2002, the wireless control device 2504, an outdoor 
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motion detecting camera, is placed in IR line of sight 2509 with respect to the 
proper controller 2500. The wireless control device actuator 2506 located on 
the wireless controlled camera 2504, embodied as a push button, is actuated by 
the proper user. In step 2004, the wireless controlled camera 2504 transmits 
5 registration information 2508 via IR and RF signals to the proper controller 

2500. This registration information is in the form of two packets of identical 
data, one via IR and one via RF, containing, in order, 



a) a first signature byte. 
10 b) a first serial number byte. 

c) a first data byte 

d) a second serial number byte 

e) a second data byte 

f) a randomly generated encryption key byte 2507 
15 g) two bytes of CRC. 



The exact order of the bytes and number of each type of byte is 
presented as an illustrative example and is not intended to limit the scope of 
the invention. 

20 In step 2006, the proper wireless controller 2500 receives the 

RF registration packet via the RF antenna 2510. In step 2006, the proper 
controller 2500 attempts to determine whether a wireless control device with 
the transmitted serial number 2505 has previously been registered. Since this 
is the first time that this registration is taking place, the proper controller 2500, 

25 with the assistance of client access device 2512, determines that such a serial 

number does not exist. Thus, the registration packet 2508 is ignored on the RF 
side. On the IR side, however, the proper controller 2500 receives the 
registration packet via the IR receiver 2514. The proper controller 2500 parses 
the registration packet and attempts to determine whether a wireless control 
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device having the transmitted serial number 2505 has been previously 
registered. Upon determining that such a serial number has not been registered, 
the proper controller 2500 registers the wireless control device 2504 by 
cataloging the relevant data along with the transmitted serial number 2505 and 
5 the encryption byte 2507. Any future transmissions from the wireless 

controlled camera 2504 will contain encrypted data bytes which are encrypted 
using the encryption byte 2507, until the wireless controlled actuator 2506 is 
pushed again. By using the IR registration method to register the wireless 
devices the first time, i.e., ignoring all transmissions from any unregistered 

10 wireless control devices 2520, including registrations transmitted via RF 

signals, the present system greatly limits the problem of accidently registering 
the wireless controlled camera 2504 along with other unregistered controllers 
2520 located within RF range. Moreover, requiring registration via IR to take 
place first, prevents unintended wireless control devices from unintentionally 

1 5 registering with local controller 2500. 

In step 2008, the wireless controlled camera 2504 is moved out 
of IR line of sight to a location 2516 that remains within RF range. In order to 
test the system to determine that the proper controller 2500 is able to 
accurately receive transmissions from the registered wireless controlled 

20 camera 2504, the user actuates the wireless controlled camera actuator 2506. A 

registration/test packet 2518 is sent from the wireless controlled camera 2504 
to the proper controller 2500 via RF signals. In fact, wireless controlled 
camera 2504 has also sent an IR transmission, but because wireless controlled 
camera 2504 is out of IR line of sight of the proper controller 2500, this mode 

25 of transmission will not be picked up by the controller. The registration/test 

packet 2518 includes 

a) a first signature byte. 

b) a first serial number byte. 

c) a first data byte 
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d) a second serial number byte 

e) a second data byte 

f) a randomly generated encryption key byte 2522 

g) two bytes of CRC. 

At this point, the new encryption byte 2522 will be used to 
encrypt all future transmission data bytes from wireless controlled camera 
2504 to proper controller 2500 until the actuator 2506 is actuated again. The 
proper controller 2500 remains in DISCOVERY mode, receives a 
registration/test packet via RF and attempts to update the registration 
information of the previously registered wireless controlled camera 2504 
stored therein, notably the new encryption key 2522 which will be used to 
decrypt future transmissions. In step 2010, the proper controller is taken out of 
discovery mode by any suitable means including actuating the proper 
controller actuator 2502. 

As best seen in FIGS. 7 and 8, in step 2012, a malicious user 
attempts to spy on the proper user's wireless controlled camera 2504 by 
registering it in a process very similar to steps 2000-2006. The details of this 
registration attempt closely mimic that described in steps 2000-2006 and are 
obvious to those skilled in the art. The steps in the authorized registration 
corresponding to steps in the malicious registration are steps 2000 and 2014, 
steps 2002 and 2016, steps 2004 and 2018, and steps 2008 and 2020. 

In step 2016, during the malicious controller actuation, a 
registration/test packet 2524 is sent to both the proper 2500, and malicious 
2505 controllers via IR and RF. The proper controller 2500 does not receive 
the IR transmission, since it is not in IR range. Since the proper controller 
2500 is in operational mode instead of DISCOVERY mode, it is alerted to the 
fact that a possible spy has attempted to register the wireless controller 2504. 
Thus, this condition is communicated to the end user via the web site as is 
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discussed below, and the user can take appropriate action. 

FIG. 9 shows an illustrative system 10 in accordance with a 
third embodiment of the present invention. For purposes of clarity, and not by 
way of limitation, an illustrative client-server based embodiment of the present 
5 invention is herein described. The system 10 illustrates how the wireless 

system 10 can be incorporated into a larger more encompassing client-server 
system. Similar references symbols are used throughout the embodiments to 
show like components. 

System 10 may include an installation 12 and a remote site 14 

10 that may be linked via a communications network 16. In practice, there may 

be more than one remote site 14 and installation 12, but only one each is 
shown to avoid over-complicating the drawing. Remote site 14 may be any 
suitable remote site that may include equipment such as, for example, one or 
more servers, mainframes, personal computers, or any other suitable 

15 computer-based equipment. Remote site 14 may include a network of suitable 

computers that may be interconnected in any suitable way, such as, for 
example, through a local area network, wide area network, telephone network, 
cable television network, Intranet, Internet, or any other suitable wired or 
wireless communications network. Communications network 1 6 may be any 

20 suitable communications network, such as, for example, a local area network, 

wide area network, telephone network, cable television network, Intranet, 
Internet, or any other suitable wired or wireless communications network. 
Some suitable wireless communications networks may be global system for 
mobile communications (GSM), time-division multiple access (TDMA), code- 

25 division multiple access (CDMA), Bluetooth, or any other suitable wireless 

communication networks. Installation 12 and remote site 14 may communicate 
over communications network 16 using any suitable protocol or protocol 
stack. For example, installation 12 and remote site 14 may communicate via a 
transmission control protocol/Internet protocol (TCP/IP) environment using, 
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for example, IP version 4 or IP version 6 (that supports 128-bit network 
addressing) and a hypertext transfer protocol (HTTP). In another approach, 
universal plug and play (UPnP) technology may be used to allow 
communication between installation 12 and remote site 14. Any suitable 
request-response type of protocol and socket-based packet transport stack, or 
suitable peer-to-peer communications approach may be used as desired. 

Installation 12 and remote site 14 may communicate using any 
suitable communications. Communications may include, for example, 
commands, requests, messages, remote procedure calls (e.g., using a proxy- 
stub pair), or any other suitable client-server or peer-to-peer communication. 
Communications may also involve, for example, complex communications 
between application constructs running on installation 12 and remote site 14. 
Objects running on the client and server may, for example, communicate using 
an Object Request Broker (ORB). Transmitted information may, for example, 
be encapsulated as COM objects or Javabeans and persisted to files that are 
transmitted over a remote access link. In another suitable approach, access 
communications may include hypertext markup language (HTML) formatted 
markup language documents (e.g., web pages), that are exchanged between 
installation 12 and remote site 14 via ISP 23 and communications link 16. For 
example, communications may comprise of a series of HTTP posts and 
responses in which the parameters for the transmissions may be sent as 
name/value pairs in the normal post method. In order to achieve the result of 
transmitting multiple commands in a single command string, numbered 
commands may be parsed out and executed at remote site 14. Remote site 14 
may be responsible for parsing the command string into individual commands 
and executing each of those commands. In order to achieve this task of 
parsing the commands, remote site 14 may utilize a script language and 
interpreter such as Personal Home Page Tools (PHP) which is embedded 
within a Web page along with its Hypertext Markup Language (HTML). For 
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example, before a page is sent to the requesting user, the Web server may call 
PHP to interpret and perform the operations called for. Other similar 
technologies may also be utilized such as JavaScript, Microsoft's VBScript, or 
any other applicable script interpreter. If desired, any other suitable client- 
server or peer-to-peer based approach may be used. 

Installation 12 may be operated by a local user. Installation 12 
may include one or more nodes. For purposes of illustration, FIG. 9 illustrates 
an approach having two nodes, first user node 18 and second user node 20. It 
should be understood that nodes 18 and 20 may be located at a single location, 
such as the user's main residence. If desired, nodes may be located across 
more than one location. For example, one node may be in a user's main 
residence and another at the user's vacation house. 

In one embodiment of the present invention, user node 18 may 
include a client device 22 that may be connected to communications network 
16. In Internet-based approaches, such as, for example, as in the embodiment 
shown in FIG. 9, client device 22 may be connected to the Internet via an 
Internet service provider (ISP) 23. Client device 22 may be any device 
suitable for communicating with remote site 14 via communications network 
16. For example, client device 22 may be a computer, a personal digital 
assistant (PDA), a terminal, a set-top box, or any other suitable device that 
provides access to remote site 14 via communications network 16. Client 
device 22 may include, for example, an Internet browser application 26 that 
may be used to access web pages via communications network 16. In other 
suitable approaches, client device 22 may run a client application that provides 
locally generated displays propagated with a format obtained using any 
suitable client-server or peer-to-peer scheme. 
Client device 22 may communicate with ISP 23 or directly with 
communications network 16 using any suitable communications link. For 
example, the link may include a telephone dial-up link, digital subscriber lines 
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(DSL), a cable modem link (e.g., a data over cable service interface 
specification (DOCSIS)), a satellite link, a computer network link (e.g., 
Ethernet link, Tl line, etc.) or any other suitable communications link or 
combination of communications links. 

Remote site 14 may include one or more servers such as, for 
example, web server 46 and database server 48. Database server 48 may 
maintain database 58. In other suitable approaches, such as non-Internet based 
approaches, remote site 14 may include an application server and any other 
suitable server or combination of servers. As herein used, the term "server" is 
not limited to a distinct piece of computing hardware or storage hardware, but 
may also be a software application or a combination of hardware and software. 
For example, one computer may have software that enables the computer to 
act as both a web server and as a database server. 

In some suitable approaches, remote site 14 may provide 
displays or display definitions to client device 22. In the Internet-based 
approach of FIG. 1, for example, web server 46 may generate static and 
dynamic web pages from data supplied by database server 48. Web page 47 
may be viewed by a user using Internet browser 26 running on client device 
22. 

Software applications interfacing installation 12 with remote 
site 14 may be created using any suitable platform and/or software 
development tools. For example, Java 2 Enterprise Edition, Javabeans, 
component object model (COM) based technologies (e.g., ActiveX, object 
linking and embedding (OLE), etc.), Javascript, Visual Basic, C, C++, 
scripting languages, or any combination of these or other suitable development 
tools may be used in creating the software interface between installation 12 
and remote site 14 (e.g., web-page interface). Any combination of these or 
other suitable development tools may be used in preparing any other software 
modules or applications for use in any other suitable facet of the present 
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invention. 

Remote site 14 may function as the master controller of the 
system shown in system 10. In addition, users may access the system shown 
in system 10 via any computer, monitoring module, or remote user access 
5 device linked to communications network 16. Remote user access devices 

(such as remote user access device 17 in FIG. 9) may include, for example, 
personal digital assistants, cellular telephones, set-top boxes, personal 
computers, or any other suitable device a user may use to access remote site 14 
via communications network 16. 
10 Monitoring modules 28 may serve as an interface between remote site 14 and 

at least one control device 32. The monitoring module 28 is equivalent to the 
controller 28 referred to in the embodiment of FIGS. 1-4. Monitoring modules 
28 may be any suitable hardware, software, or a combination thereof and may 
be included at any point within the system. For example, monitoring module 
1 5 28 may be a software application running on client device 22 or a separate 

piece of hardware that may be connected to client device 22 (as shown at node 
18) or partially implemented as software on client device 22 and a separate 
piece of hardware. In some embodiments, monitoring module 28 may be a 
stand-alone appliance (as shown at node 20) connected to communications 
20 network 16, operating separately and independently from client device 22. 

Each monitoring module may be shipped with a model identification code, or 
with the capacity to generate such a code, that may serve to identify each 
particular monitoring module's model type. 

One or more monitoring modules or service brokers may be 
25 installed at one or more locations. Monitoring modules may be installed by 

the user (or any other suitable person) by, for example, connecting the 
modules to client device 22 that may communicate with remote site 14 over 
communications network 16. The connection between the monitoring module 
and the client access device and between devices and the monitoring module 
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may be in the form of a universal serial bus (USB) connection, parallel port 
connection, serial connection (e.g., RS-232), Firewire connection, any 
combination of these, or any other suitable type of connection. If desired, 
monitoring modules may be given the capability (e.g., processing hardware, 
communications equipment, etc.) to communicate, via communications 
network 16, without the use of a client access device. Monitoring modules 
may link attached devices or appliances (e.g., sensors, cameras, microwaves, 
refrigerators, etc.) with remote site 14 via communications network 16. One 
or more monitoring modules 28 may provide data from attached devices and 
appliances to remote site 14 via communications network 16. The term 
"device," as defined herein, shall include any suitable device or appliance 
whether it is wired or wireless. 

At least one device 32 may be interfaced with and controlled by 
each monitoring module 28. Connections between monitoring module 28 and 
the various devices 32 may be hardwired or wireless such as described in 
connection with the first embodiment of FIGS. 1-4. Devices 32 may 
encompass any suitable device capable of being controlled or mediated by an 
external controller. Such devices may include, but are not limited to, a camera 
34, a radio 36, a wireless smoke or fire detector 38, a wireless contact sensor 
40, and a wireless light switch 41. Although not illustrated, other suitable 
devices may include, for example, various audio input and output devices, 
various visual displays, washers/driers, microwave ovens, cooking ranges, car 
alarms, plant watering devices, sprinkler, thermostats, carbon monoxide 
sensors, humidistats, rain gauges, video cassette recorders, radio tuners, or any 
other suitable device and the like. 

One or more notification devices, such as pager 43, may also be 
incorporated into the system. As illustrated in FIG. 9, pager 43 is in wireless 
communication with a wireless or cellular transmitter 44 associated with 
remote site 14. Other suitable notification devices include, for example, e- 
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mail clients, wireless hand-held computers, wireless wearable computer units, 
automatic web notification via dynamic web content, telephone clients, voice 
mail clients, cellular telephones, instant messaging clients, and the like. 

System 10 provides users with opportunities to remotely 
control and monitor devices 32 using remote user access devices 17 via 
communications network 16. In the example of FIG. 9, users may control 
devices 32 that are interfaced with monitoring modules 28 at node 18 and 
devices 32 interfaced with monitoring module 28 at node 20. In practice, there 
may be a single node, or more nodes, depending on, for example, the user's 
equipment, number of sites, or other suitable parameters. In practice, a 
suitable system architecture and communications network 16 may allow users, 
or anyone that users permit, to readily monitor and control monitoring 
modules 28 from any location using any suitable device that is capable of 
communicating with remote site 14 via communications network 16. 

In another suitable approach, users may access installation 12 
using remote user access devices 17 without the use of remote site 14. For 
example, remote user access devices 17 may be used to communicate with 
monitoring modules 28 of installation 12 via communication network 16 and 
ISP 23. If desired, two-way communications may be implemented using this 
approach. Remote user access device may access installation 12 using, for 
example, special IP addresses assigned to a particular monitoring module, 
node, installation, or any other suitable element of the installation. The use of 
IP addresses is merely illustrative. Any other suitable addressing may be used 
to allow access to an installation from a remote used access device. 

Devices 32 may be programmed at the installation in terms of 
how they respond to certain events (e.g., what does the camera do when the 
contact sensor is triggered?). Alternatively, devices 32 may be programmed 
from a remote location using remote user access device 17, for example. The 
programming may be stored in devices 32, monitoring modules 28, or at 
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remote site 14. 

The following examples of the uses of illustrative devices will 
illustrate the operation of the present invention. For example, contact sensor 
40 of FIG. 9 may be associated with the front door (not shown) of a remote 
location associated with second node 20. Contact sensor 40 may be configured 
to trip whenever the front door is opened. Camera 34 is also positioned to 
view the front door location and may be programmed to take a digital picture 
whenever the sensor contact 40 is tripped. This picture may be transmitted 
over communications network 16 and stored in database server 48. When 
contact sensor 40 detects that the front door has been opened, an event 
notification or alarm trigger may be transmitted by monitoring module 28 to 
database server 48. Database server 48 may have been previously 
programmed to transmit a notification event to the user's pager, for example, 
via cellular transmitter 44. As the contact sensor is tripped, camera 34 may 
take a picture of the front door and may transmit that picture, via monitoring 
module 28 and communications network 16, to database server 48. The user, 
having been notified via pager 42, may now access the picture using web 
server 46 of remote site 14 via Internet browser 26. In this way, the user may 
determine who has entered the front door of his or her home. 

As another example, system 10 may allow a user located at one 
node 18 to control a device at a second node 20. The user may contact web 
server 46 via, for example, Internet browser 26 of node 18 in order to access a 
database entry for light switch 41 of node 20. A virtual representation of the 
light switch 41 may be made available to the user by web server 46 and may 
be manipulated by the user to remotely change the state of light switch 41 and 
the connected lamp 42. For example, the system may allow the user to change 
the state of lamp 42 from being "off ' to being "on" by, for example, 
manipulating the virtual light switch from web server 46 and a corresponding 
command would be placed in the queue of waiting commands on the server 
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component. 

Periodically, the controlling module or monitor 28 may poll 
remote site 14 looking for waiting commands, such as the change state 
command of light switch 41 . Thereafter, the command may be transmitted to 
monitoring device 28 that would instruct the light switch to change from the 
"off 1 state to the "on" state, thus turning on lamp 46. This change in state of 
lamp 46 may be viewed by an appropriately positioned camera, such as camera 
34 ? which would be used to visually monitor the remote location 20 to 
determine whether the command had been completed successfully. If the 
command had not been successfully completed, then an error message may be 
communicated to the user, using for example, the means specified by the user's 
notification preferences or through any other suitable means of communicating 
information to the user. This is merely an illustrative approach for detecting a 
change is state of a device. In another suitable approach, lamp 46 may be in 
two-way communications with a corresponding device driver. The device 
driver may query the lamp to determine whether it was on after executing a 
"turn on" command. Any such suitable approach may be used for detecting a 
state in change of a device. 

Referring now to FIG. 10, monitoring module 28 may serve, for 
example, as a common connection point for one or more devices 32 at an 
installation 12 and as the interface between devices 32 and remote site 14 via 
communications network 16. Monitoring module or service broker 28 may, 
for example, serve as a translation and brokering agent between remote site 14 

and devices 32. 

In one suitable embodiment, monitoring module 28 may be 
software made up of multiple dynamically loaded objects, or device 
descriptors 49, that may allow remote site 14 to interface with the devices 32. 
The dynamically loaded device descriptors 49 may act as device drivers for 
devices 32, translating, in both directions, monitoring, command, and control 
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data exchanged between monitoring module 28 and remote site 14 via 
communications network 16. Each device descriptor 49 may also translate the 
signals received from monitoring module 28 into the specific electrical signals 
that are required to communicate with (both input and output) and control its 

5 associated device 32. Device descriptor 49 may be provided for each specific 

device 32 when, for example, different devices 32 have different interfaces and 
require specific sets of electrical signals for their monitor and control. 

Device descriptors 49 may include, for example, a 
manufacturer identification, product identification, and driver version number 

1 0 to allow a device to be referenced correctly. Once a new device 32 has been 

detected and is to be integrated into the system, monitoring module 28 may 
reference, download, and run the appropriate drivers for the new device. 

After loading a new descriptor 49, monitoring module 28 may 
communicate with remote site 14 to determine whether device 32 has been 

15 previously catalogued. Monitoring module 28 may, for example, determine if 

a general description and a default state of device 32 exists at the remote site. 

When a device 32 has been catalogued, then, for example, static 
parameters, such as the manufacturer name, may be communicated from 
monitoring module 28 to remote site 14 and the default state of device 32 may 

20 exist at remote site 14. When a device 32 is not already catalogued, device 32 

may communicate its default state and static parameters to monitoring module 
28 that may, in turn, communicate the default state and static parameters to 
remote site 14. The communication from monitoring module 28 to remote site 
14 may be done using name/value pairs using, for example, the normal HTTP 

25 post method discussed hereinbefore. For example, a template document may 

be a static parameter of device 32. 

FIG. 1 1 shows five devices, 32, 32a, 32b, 32c, 32d. In practice, 
there may be more or fewer devices with each installation. Each device may 
be interfaced to a monitoring module 28 via a device descriptor or driver 49 
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(only one shown). Each device may include a customizable user interface 58 
that may be viewable on a remote user access device over communications 
network 16. Interfaces 58 may include virtual representations of the actual 
user interfaces of the devices. 

In another approach, virtual representations may be stored on, 
for example, web server 46. Remote site 14 may use changes in device states 
to change the virtual representations of the devices with which the changed 
states are associated. A virtual representation of a device, as previously 
described, may be either a text-based, symbol-based, or image-based 
representation of an actual device 32 from the installation as it appears to a 
user who accesses the remote site from a location remote to the installation 
using any suitable remote user access device. For example, if the device is a 
light switch, the corresponding virtual representation may be an indicator icon 
that may be either green or red. If the indicator icon is green, that may denote 
that the actual light switch is in the "on" position. If the indicator is red, that 
may denote that the light switch is in the "off position. If, during a heartbeat 
operation, remote site 14 is informed that the state of the light switch changes 
from "on" to "off," then the virtual representation of the light switch may 
change from being green to being red. 

User interface 58 may include at least one resource. In the 
example of FIG. 11, resources 60, 62, and 64 are shown. Resources may 
provide users with access to features specific to their associated device. For 
example, the device shown in FIG, 1 1 represents a videocassette recorder 
(VCR) having a recording setting resource 60, a channel selecting resource 62, 
and a power selecting resource 64. Typical VCRs may have other operational 
resources, but the resources illustrated in FIG. 1 1 are sufficient to illustrate the 
operation of the device. 

Each resource 60, 62, 64 may include one or more display 
components. For example, the recording setting resource 60 includes a display 
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component 70 and a series of pushbuttons 72, 74, 76, 78 which a user may use 
to activate the VCR's fast forward, reverse, play, and stop functions, 
respectively. The channel selecting resource 62 may include the display 
component 70 and a pair of pushbuttons 82 that users may use to activate up 
channel and down channel functions of the VCR. The power selecting 
resource 64 may include a toggle switch 80 that user may use to activate the 
VCR's power on and power off commands, and an LED indicator 81 that may 
indicate the power condition of the VCR. 

Other suitable display components may include toggle buttons, 
radio buttons, absolute sliders, proportional sliders, edit fields, labels, images, 
video clips, streaming video, streaming audio, multiselect list, time fields, date 
fields, N-directional components, N-state buttons, N-state selectors (where N 
may be any suitable integer), trees, tables, graphs, charts, drawing pads, 
streaming audio, banners, or any other suitable display components. Display 
components may act as status indicators. If desired, display components allow 
users to toggle settings or otherwise manipulate devices 32. For example 
toggle buttons may serve as indicators, showing, for example, whether a 
device is in the M on" position or in the "off" position. Toggle buttons may 
allow users to change the state of a device, by, for example, turning a device 
on or off. Sliders may act as indicators by showing, for example, the 
percentage complete of a particular process a device may be performing (e.g., 
baking a cake), and may allow users to change the state of a device (e.g., 
changing the thermostat temperature). Edit fields may allow users to change 
textual representations of suitable elements (e.g., naming a television show to 
be recorded by the show's name). Video, audio, images, or any other suitable 
media-based components may act as indicators showing what the devices are 
sensing (e.g., images may be sensed by cameras, streaming video may be 
sensed by camcorders, audio clips may be sensed by audio recorders, etc.). 
Date and time fields may act as indicators, by, for example, displaying what 
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date and time a VCR is set to start recording. Date and time fields may allow 
users to set the date and time a VCR may start recording. Multiselect lists 
may act as indicators by, for example, listing all sound sensors that are 
detecting noise in the house. Multiselect lists may also be used, for example, 
to select some of a number of available sensors to turn on. 

A virtual representation of each device 32, 32a, 32b, 32c, 32d 
may be stored as a record 94, 94a, 94b, 94c, 94d in the database of database 
server 48 of remote site 14. Each record may contain an entry for each 
resource and its associated components which make up the device. For 
example, record 94 for VCR device 32 may contain an entry 90, 91, 92 for 
each resource 60, 62, and 64, respectively, and an entry 90a, 90b, 90c, 90d, 
91a, 91b, 92a, and 92b for each component 70, 72, 72, 74, 80, 81, and 82, 
respectively. In addition, a web page 47 may be generated by web server 46 
by extracting the associated record for that device from database server 48 and 
creating a graphical, textual, tactile, aural, or other similar modality user 
interface representation of that device that the user may access via, for 
example, Internet browser 26. 

One of the functions that monitoring module 28 may serve is to 
persist the state of devices 32. This may be done, for example, to allow the 
real-time states of devices 32 to be stored, to communicate to remote site 14, 
or to allow for easy recovery from a system crash. 

The stored state of devices 32 may also be used for maintaining 
a synchronized relationship between an installation 12 and remote site 14. In 
one possible embodiment of the present invention, remote site 14 and 
installation 12 may use polling and heartbeat mechanisms in order to 
synchronize state information between remote site 14 and installation 12. 
Polling may refer to a process whereby monitoring module 28 obtains 
commands from remote site 14. The commands may reside, for example, in 
command queue 5 1 . Commands may be accumulated at command queue 5 1 



753070.3 



as a result of any suitable action by the user, by remote site 14, or by both. For 
example, a user may use a remote user access device to issue a command or a 
request to remote site 14 to cause a change in state of one of devices 32 (e.g., 
to turn a lamp on). Remote site 14 may post the change in state command to a 
command queue 51. 

Monitoring module 28 may communicate a request for pending 
commands to remote site 14. This request may be communicated periodically 
as part of the polling process. In response to the monitoring module's request, 
remote site 14 may provide one or more pending commands from command 
queue 51, and may notify monitoring module 28 of the number of remaining 
pending commands in command queue 51. Monitoring module 28 may then 
again communicate a request for pending commands. Remote site 14 may 
return more of the pending commands from command queue 5 1 . This process 
may continue until command queue 51 at remote site 14 is empty. 

Remote site 14 may provide commands to monitoring module 
28 using any suitable algorithm. For example, remote site 14 may return 
commands using first-come, first-serve, round robin, first-in, first- out, 
weighted prioritization, or any other suitable algorithm. Remote site 14 may 
also proactively inform monitoring module 28 that commands are waiting in 
queue 51. Monitoring module 28 may then poll remote site 14 and retrieve 
commands from remote site 14 until the queue is empty. 

Whereas polling process 50 is used by remote site 14 to effect 
state changes in devices 32 via monitoring module 28, monitoring module 28 
may use heartbeat process 52 to update device state information at remote site 
14. A heartbeat may be a periodic communication from monitoring module 28 
to remote site 14 containing updated state information for devices 32 
associated with monitoring module 28. In one suitable heartbeat process 52, 
monitoring module 28 may send a communication to remote site 14 in 
response to a change in state of a device 32, a synchronization of a device 32 
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with remote site 14, a triggered alert event, or in response to any other suitable 
event. In such a heartbeat operation 52, all data intended to be transmitted to 
remote site 14 may be transmitted to remote site 14 via communications 
network 16. Remote site 14 may transmit an acknowledgment of receipt and 
successful processing of the data back to monitoring module 28. 

Remote site 14 may direct monitoring module 28 to make 
changes in its own state by, for example, posting commands to data store 51. 
For example, remote site 14 may post commands that set or modify the polling 
50 or heartbeat 52 time intervals. Upon reaching the end of the current polling 
interval, monitoring module 28 may send a communication to remote site 14, 
requesting any queued commands. Monitoring module 28 may continue to 
poll, using a preselected communication scheme, until the queue of commands 
waiting for monitoring module 28 is empty. Each command received from the 
queue may be acted upon when the command is received and any associated 
state changes are effected. Remote site 14 may transmit an acknowledgment 
of receipt and successful processing of the data back to monitoring module 28. 

If desired, remote site 14 may send unsolicited communications 
to monitoring module 28. Remote site 14 may send communications to, for 
example, set or update the heartbeat or polling time, or to cause monitoring 
module 28 to issue a command to update a component of a device. Remote 
site 14 may send unsolicited communications to monitoring module 28 for any 
other suitable purpose. 

In addition to maintaining the polling and heartbeat operations 
and exchanging communications for events, data, and commands 54 with 
remote site 14, monitoring module 28 may also take care of many network 
level activities 56. These activities may include, but are not limited to 
verifying passwords, dialing up an ISP, if necessary, periodically uploading 
accounting/billing information, and performing security measures. Any other 
suitable network level activities may be performed by monitoring module 28. 
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While certain preferred embodiments and various modifications 
thereto have been described or suggested, other changes in these preferred 
embodiments will occur to those of ordinary skill in the art which do not 
depart from the broad inventive concepts of the present invention. 
5 Accordingly, reference should be made to the appended claims rather than the 

specific embodiment of the foregoing specification to ascertain the full scope 
of the present invention. 
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